PD ROM 1

home *** CD-ROM | disk | FTP | other *** search

/ PD ROM 1 / PD ROM Volume I - Macintosh Software from BMUG (1988).iso / Electronic Messages / Delphi Digests / Delphi Vol. 2 / Delphi 2.36 < prev next >

Wrap

Text File | 1986-08-13 | 25.4 KB | 667 lines | [TEXT/ttxt]

del Message 1432601 has been deleted. Message: 1434680, 641 lines Posted: 8:37pm EDT, Tue Aug 12/86, imported: 4:23am EDT, Wed Aug 13/86 Subject: Delphi Mac Digest V2 #36 To: Peter_Johnston@UQV-MTS, PC Macintosh, MacTechnics User Group, John Dorsey, Alex_Ranous@UB-MTS, Abraham Vanderspek From: SHULMAN@RED.RUTGERS.EDU Delphi Mac Digest Tuesday, 12 August 1986 Volume 2 : Issue 36 Today's Topics: RE: List Manager LDEF (Re: Msg 525) RE: Very Weird Problem (Re: Msg 542) RE: Very Weird Problem (Re: Msg 553) RE: Very Weird Problem (Re: Msg 552) RE: Very Weird Problem (Re: Msg 553) RE: Very Weird Problem (Re: Msg 542) RE: Very Weird Problem (Re: Msg 563) RE: Very Weird Problem (Re: Msg 563) Laserwriter FONDs Driver Needed lightspeed c RE: lightspeed c (Re: Msg 11541) RE: LW cartrige recharging Medical Uses of a MAC RE: Medical Uses of a MAC (Re: Msg 11554) RE: Medical Uses of a MAC (Re: Msg 11554) Medical Uses of a Mac RE: lightspeed c (Re: Msg 11541) Paranoia Vindicated RE: Paranoia Vindicated (Re: Msg 573) RE: Paranoia Vindicated (Re: Msg 575) char speed lightspeed C (more grumbles) RE: lightspeed C (more grumbles) (Re: Msg 11617) RE: lightspeed C (more grumbles) (Re: Msg 11622) RE: lightspeed C (more grumbles) (Re: Msg 11623) ----------------------------------------------------------------------- From: MARSHG (551) Subject: RE: List Manager LDEF (Re: Msg 525) Date: 9-AUG-12:37: Developers' Corner Strictly speaking, yes that extra byte is the high half of the word that the compiler uses. I just like to think of it as structure alignment... The problem is that somewhere inside the list manager, the code checks for the signed byte to be negative rather than for the bit being set hence the need -for filling the upper byte with -1's. As far as the scroll bars disappearing, that's the way IM says scroll bars shoul be implemented. I think it's a little strange but I do like the Bible says... Marsh ------------------------------ From: PEABO (553) Subject: RE: Very Weird Problem (Re: Msg 542) Date: 9-AUG-16:29: Programming Techniques I bet something is trying to use A0 to reference memory. Mouse-freeze is caused by trying to reference memory above 8 megabytes, due to the cretinous design of the Mac hardware (TAKE THAT BURRELL SMITH! ZAM! POW!) The problem is that all the I/O logic is wired into the upper 8 megs of address space, and the command, status, and data registers of these I/O devices respond to 'memory' reads and writes over many, many thousands of bytes of address space, and they do things when referenced, such as reset the SCC (and hence lose mouse interrupts). This was done because it saved a few gates in the design of the Mac digital board. It was a "neat hardware hack". I think it makes the Mac a unnecessarily fragile programming environment, and -I mutter under my breath everytime I do something that causes a mouse freeze because I know what a trivial programmer error can cause it. peter ------------------------------ From: ASMCOR (557) Subject: RE: Very Weird Problem (Re: Msg 553) Date: 9-AUG-22:09: Programming Techniques Peter - I've never heard it explained before... do you know how to unfreeze the mouse, then? Like TMON does? Jan ------------------------------ From: LOFTUSBECKER (559) Subject: RE: Very Weird Problem (Re: Msg 552) Date: 10-AUG 00:49 Programming Techniques What do you mean, "then using A0 as an address"? The hangup comes _before_ any instructions other than Move.L #$28EFFFF,A0 are executed! I am beginning to think that this may be a bug in TMON, since it must be doing something to make the move, display results, etc., etc. But the problem definitely isn't anything I'm doing afterwards -- it happens even if I don't do anything afterwords. - Lofty ------------------------------ From: LOFTUSBECKER (560) Subject: RE: Very Weird Problem (Re: Msg 553) Date: 10-AUG 00:51 Programming Techniques Hmm. Okay, that's probably what's causing the freeze. So maybe it's a bug in TMON? (all right, all right -- a feature). Sounds as if I should boot up with Macsbug and see if that has the same problem. If not, it's definitely TMON. - Lofty ------------------------------ From: LOFTUSBECKER (563) Subject: RE: Very Weird Problem (Re: Msg 542) Date: 10-AUG 02:53 Programming Techniques Mystery solved. It came from the fact that a read to any of quite a few high-memory addresses (above the Mac's real address space) will reset the serial ports, with disastrous consequences for the mouse; and the fact that, while running TMON, one window I had open displayed the memory starting at the address in A0. The result was that when I loaded a large number into A0, TMON would quite properly try to read the memory that A0 pointed at. This read would cause the mouse freeze. It's not a problem with my Mac, and not really a bug in TMON. But it's worth a warning: if you get a mouse freeze while debugging, look to see what windows you have open and whether (as I did) you are accidentally causing high-memory reads. (much relieved) Lofty. ------------------------------ From: MACLAIRD (564) Subject: RE: Very Weird Problem (Re: Msg 563) Date: 10-AUG 04:08 Programming Techniques Perhaps we need a _SCCReset trap? _Laird ------------------------------ From: PEABO (567) Subject: RE: Very Weird Problem (Re: Msg 563) Date: 10-AUG 15:33 Programming Techniques I think it's a bug in TMON. The restrictions on accessing high memory are -well known to the guy who wrote it (after all, he wrote an unfreeze routine!!) so I think he should check for that kind of thing before doing an automatic refresh of an anchored window. Yes, it should be possible to read or write the I/O space from the debugger, but you should have to work at it to do it. peter ------------------------------ From: DSACHS (11530) Subject: Laserwriter FONDs Date: 9-AUG-23:03: Programming I have noticed that the flag word n the FOND resources for the Laserwriter ( except Courier) has a value of $1000. According to the documentation in the latest supplement, bits 2-12 of this word should be zero. Can anyone cast further light on this situation? ------------------------------ From: GTALMO (565) Subject: Driver Needed Date: 10-AUG 04:29 Programming Techniques Hello; I'm looking for a ( hoppefully free) modem driver for use with MS BASIC. i.e. -I will be writing a BBS program in MS BASIC, and I don't really wnt to wright my own driver (If there's allready one out there). Also any help in finding -XMODEM subroutines would be VERY helpful. Thank You! Greg TALMO ------------------------------ From: CHUQ (11541) Subject: lightspeed c Date: 10-AUG 04:46 Programming I've got some questions/comments on LightSpeed C. Anyone want to help out or kibbitz? o I'm running into "out of memory" errors. Usually when I have a window open to a changed file. It always happens when after the compile, probably when the code is being written into the segment. My segments are about 30K or so. I'm running a 512K with RAM HFS. Is the memory used by HFS THAT critical to LSC? Closing the open windows or moving the module to a new, smaller segment solves the problem. (sigh) o Related: LSC doesn't talk about tuning. Am I better off with fewer, larger code segments or lots of small ones (say one per module)? I'm porting a major piece of Unix code, to the tune of 54 .c files and 20+ .h files. Total -compile from scratch is about 70,000 lines. o Comments: There are some major missing pieces to the Unix side of LSC. index () and rindex() are missing, although strchr() and strrchr() are there. The directory reading routines (readdir(), opendir(), etc...) are gone, as is stat() and fstat(). this means that any Unix program that touches or looks for a file has to be hacked to use Macland oriented calls. feh. Major reduction in utility of the emulation, and that stuff could all be handled without a lot of hassle. o There is NO earthly reason why some of the "unix" calls couldn't be generalized away from the emulation. Like printf(). Why force us into a -glass tty for these things when you could make our life easier hacking Mac programs? again, a strange restriction of functionality. I should point out that it took me about 10 hours from the time I downloaded that code (about 400K of source) to the time I got it compiled and run, including hacking out some Unix stuff I couldn't emulate (and didn't need) and hacking in replacements for Unix stuff I didn't have and DID need (like curses based routines). Overall, I'm now REAL impressed, although there is a strong tendency for LSC to degrade in really large environments like this. Clicking "multi-file-search" takes forever, for example, and doesn't cache so every -time you start it you can go get a Coke or something. Running it (and returning to LSC) also take a long time. Relatively speaking. Oh, well. when I tried to port this code in Mac C, I gave up in disgust after a month of trying to get it compiled. I guess THAT says something, too.... chuq ------------------------------ From: PEABO (11557) Subject: RE: lightspeed c (Re: Msg 11541) Date: 10-AUG 15:53 Programming The more segments you have, the larger your jump table (in CODE 0) will get. There is a little bit of overhead from the jump (after the target segment is loaded), but thats all. You might also consider the overhead of having more objects in the heap, of loading (or preloading) the extra segments, and of tying up more heap because of the larger CODE 0. If you have any segments with libraries in them, then may build to be smaller than they link (because unused modeuls are discarded during the build). What that means is that a segment that you know perfectly well will fit in 32K may fail to link because of excess baggage. What I wound up doing is sticking most of the Lightspeed library code off in a segment by itself, where it's guaranteed to fit. The 'Out of Memory' error has only happened to me when I had a mangled .RSRC file. (But I am living in luxury with a megabyte of RAM ...) You should be aware of this other way of getting that message though. I guess you will have to close your windows before linking. I found the LightspeedC library to be very poorly organized ("Hello, world" drags in an incredible amount of stuff, and anything that calls exit() does too, even if it isn't explicitly using the standard I/O package.) Overall, I like MANX's approach to a shell a lot better than LightspeedC. peter ------------------------------ From: MOUSEKETEER (11552) Subject: RE: LW cartrige recharging Date: 10-AUG 14:01 MUGS Online To: brucer@pwcs.UUCP (Bruce Alan Riebe) For info on recharging Laser carts (either purchase recharged, send in for recharging, or do-it-yourself kits) contact: Laser Printer Products, 11 Freeman Street, Stoughton, MA 02072 (617) 893-9000 (24 hrs.) or (617) 341-3005 (9-5 Eastern, human voice...near mooselike). A kit to recharge 2 carts and manual is $99, toner for charging one cart is $20, recharging service is $40, etc.). While you can save a few bucks by going this route, my incentive was more to attain a better print-out from the Laserwriter. The folks have done a lot of work to determine the optimum toner and procedure, and the results from the carts is (to my eye) much nicer than an Apple supplied cart...deep blacks! Note: They also sell "Laserlube and Clean" Disks for monthly cleaning, though I haven't the foggiest what they are or how they work. Alf ------------------------------ From: PUGDOG (11554) Subject: Medical Uses of a MAC Date: 10-AUG 14:16 SIG Business I do not visit this sig very often, infact, upon entering this sig, I was informed my access was purged in Jan, and well, you know how it goes. One of the main reasons I do not visit this sig very often, is that I am a confirmed IBMer. (As was my stance in the IBM vs MAC debate). BUT, lately, due to availability at work, I have been playing with the MAC a little, and realize it does have some nice features. I am still not convinced it is a legitimate machine for anything but graphics, ESPECIALLY FOR USE IN MEDICINE -- I AM NOT CONVINCED! In fact, no one has been able to convince me. I haven't found one legitimate application -- enven "manufacturers" of "rumored" products have not sent the information they have promised. I am in medical school, and am designing and installing medical office systems. I would like a good package for the MAC. BUT I need to FIND ON first!!! Does anyone out there know of one? Can anyone out there sned, or have the manufacturer send, information? My attitude is, If I inquire about distributing a product, I SHOULD NOT BE THE ONE TO HAVE TO FOLLOW UP ON IT! I am looking for a manufacturer that stands behind their product. (That is why I am at the point of REFUSING to sell IBM's system). Not one manufacturer of MAC based systems I have contacted has followed through. I can't work with a manufacturer who's attitude is that he is doing ME a favor by letting me sell his product. I need one who hustles as much as I do, and for whom each sale is as important as -- or mor important -- than anything else. If you can help, I'd appriciate it. I might even be convinced to say that the MAC is pretty neat, :-), -r- Robert S. Pataki Professional Systems Consultant Medical Systems Specialist President, Man & Machine Integration: The BioDigital Connection, Inc. (PS. The medical systems I install are backed by the services of Computer Corp. Of Westchester, which owns 4 ComputerLand franchises, and a Corporate/Outside Sales Office. So, I need a Software Package that lives up to our reputation.... Thanks....) ------------------------------ From: JIMH (11564) Subject: RE: Medical Uses of a MAC (Re: Msg 11554) Date: 10-AUG 17:44 SIG Business Bob, if the mac isnt a serious machine for medicine why does the local med school use them both for the professors, and all the student courses on computeres in medicine are taught on them. they are also writing a computers -in medicine textbook for u se with a mac. jim ------------------------------ From: LAMG (11575) Subject: RE: Medical Uses of a MAC (Re: Msg 11554) Date: 10-AUG 20:37 SIG Business Robert: I think that saying that "the Mac isn't a good machine for medicine" is an unfair generalization. It may very well be that none of the medical office management systems are adequate or well-supported; I've just begun to look into them myself for a Medical Mac SIG I'm organizing. But there's much more to medicine than office management... I use the Mac for everything from writing manuscripts for publications to creating exhibits for meetings to organizing and managing patient data. There's also a lot of interesting work being done on using the Mac for medical compter assisted instruction. I have no hesitation in recommending the Mac to other physicians, though if -the need is for office management software the system has to be checked out thoroughly first. I'd like to know which companies you've had such a poor response from. -Franklin Tessler, M.D. / LAMG ------------------------------ From: PIZZAMAN (11586) Subject: Medical Uses of a Mac Date: 10-AUG 23:47 SIG Business Bob, I would have to agree with Franklin Tessler that the Mac is a wonderful tool for the physician who is in the business of information transfer. Many fields of medicine are very visually dependent, such as radiology, pathology, surgery, etc. In order to transfer information, diagrams are often a necessary part of the process. There is no better desktop computer on the market for this type of work. Granted, the office management software hasn't caught up yet, but it seems that simple accounting and database management would be a snap for the Mac+ with any of the presently available hard disks. I would be very surprised if someone doesn't have a very nice package available in a short period of time. I know that many of my friends in the medical field would Macintize their offices in a minute if the software was available. By the way, there is software available right this very moment for sportmedicine. I happen to have a nice template for Filevision that combines anatomic diagrams interactively with the database of information on various jogging, skiing, etc. minor injuries. It is a very effective way of keeping track of this information, for reference as well as patient education. I'd be glad to send you a demo if your interested. I don't believe that there is anything on the IBM that even comes close to the filevision program. Barry ------------------------------ From: DWB (11596) Subject: RE: lightspeed c (Re: Msg 11541) Date: 11-AUG 02:37 Programming Hi Chuq, strchr and strrchr are the system v equivalents of index and rindex. Hack should already have floating around in it somewhere the ability to make it compile for sysV. If it does turn it on and that problem should go away. If it doesn't put '#define index strchr' and '#define rindex strrchr' somewhere in a global include file. This is actually a fairly major (# of occurences, not time to fix) problem in porting unix code amongst machines. If you haven't yet kludged up the directory routines and stat (fstat is harder though) and you need them, let me know. I have some stuff that can be easily and quickly modified to give you that. BTW, I have a port of the 4.2BSD ar program if you have a source license and want/need it. Unfortunately it only works as a project. Guess this stuff really should have been done via usenet as more folks there are probably interested in it than here, but here's where I saw your note. I tend to ignore the Lightspeed libraries (except for MacTraps) and drag in precisely what I need. But, then again, I don't like to settle for command line interfaces anyway. Yuk! Good luck. David ------------------------------ From: LOFTUSBECKER (573) Subject: Paranoia Vindicated Date: 10-AUG 23:48 Programming Techniques THE VINDICATION OF PARANOIA, or, A Strange Bug and How To Avoid It. I thought I would post a report of a strange bug I came across and how I have (I hope) fixed it. For some time I've been working with DA Key 2.1, and found it had an occasional, and generally unreproducible, habit of freezing the mouse (and my MacBottom) shortly after the SFGetFile dialog. I finally found an odd series of events that made it repeatable (involving the Aztec Shell), and started tracking it down. Here's what I found. _OpenResFile is passed a pointer to a string. I passed the pointer by doing a LEA (stringaddr),A0; Move.L A0, -(SP). In some circumstances, depending on the previous contents of A0, the result of the LEA would not be simply the address (i.e, not simply 00xxxxxx, but rather A0xxxxxx). In theory (I think) this shouldn't make a difference. In practice, however, this would often cause the mouse freeze. Tracing through the ROM, I found that at one point the _OpenResFile routine does a _RecoverHandle on the string pointer passed to it. If that string pointer was passed not as 00xxxxxx, but as A0xxxxxx, _RecoverHandle will -- sometimes -- freeze the mouse. I can now replicate the freeze with ease. The solution? A few more bytes. Instead of LEA [stringaddr],A0 Move.L A0,-(SP) I now do a LEA [stringaddr],A0 Move.L A0,D0 And.L #$00FFFFFF,D0 Move.L D0,-(SP) This assures the high byte is cleared and seems to have removed the bug. The moral, I suppose, is that those who have paranoiacally been clearing the high bit of all addresses are right. Does anyone know (a) why LEA doesn't do it automatically? (b) any more details about this apparent ROM bug, and whether Apple is aware of it? (c) an easier way to do things? - Lofty ------------------------------ From: DWB (575) Subject: RE: Paranoia Vindicated (Re: Msg 573) Date: 11-AUG 03:03 Programming Techniques Instead of using lea addr,a0 move a0,-(sp) try using pea addr it does the same thing, (well almost a0, doesn't have the -address, but then after the trap it doesn't anyway, so....), takes up fewer bytes, and probably puts appropriate stuff in the high byte. The 68K probably doesn't clear that byte because it doesn't expect the outside world to ever see it. Lame excuse but... Lot's of things were done to save microcode. RecoverHandle probably barfs on '0xA0000000' because that A0 gets interpreted as a flag byte and means it's a locked resource and thus there must be a handle for it somewhere. Conjecture here! David ------------------------------ From: LOFTUSBECKER (576) Subject: RE: Paranoia Vindicated (Re: Msg 575) Date: 11-AUG 04:04 Programming Techniques Hmmm. I never did look at IM on flag bytes. That could be the problem. I'll see whether PEA has similar problems. Incidentally, I've noticed that Aztec C generates similar code (using LEA not PEA), and has sometimes given me similar problems.... - Lofty ------------------------------ From: JOSEF (577) Subject: char speed Date: 11-AUG 21:17 Programming Techniques This issue of what baud rate the Mac can run at and keep up really has me puzzled. A long time ago I wrote a communications program for the Mac which peaked out at about 2400 baud. I also remember someone telling me that DrawChar() took about 300 microseconds to draw a character to the screen, -which implies that 9600 baud should be no sweat. So today I wrote a program that sits in a tight loop just doing DrawChars. The average time per character came to about 1.5 ms. Since this seemed unusually long, I fired up QUED, filled a window with 2000 characters, covered that with another window, then reactived the full window; LO & BEHOLD, the window was redrawn in something that was clearly less than a second, which makes 300 microseconds sound entirely believable. What's going on here? Obviously my "for" loop does not use up an overhead of 1.2 ms per character, so what does the TextEdit Manager know that I don't? Joe ------------------------------ From: CHUQ (11617) Subject: lightspeed C (more grumbles) Date: 11-AUG 21:52 Programming I think I'm starting to sound like a crotchety old man. You'd never GUESS that I love LSC. IF you are running a 512K, and IF you are running old ROM's AND the RAM HFS, AND MACSBUG, Lightspeed C becomes VERY memory bound. It is fairly obvious they use ALL of the 512K. You can't compile anything with a modified open window, you can't use segments larger than about 10K, and you have to be willing to coax it along. At one point, it wouldn't load its own <stdio> library (16K) into its own segment with nothing else at all taking up memory except the make. Manually using "load library" did the job, though. This is real nasty. I am gonna see if I can find a ROM upgrade this week, but people should be aware that LSC wants LOTS of memory. I suggest (from this kind of memory usage) people should plan on 1 Meg for serious LSC development. It's STILL a helluva compiler... chuq ------------------------------ From: VINDICATOR (11622) Subject: RE: lightspeed C (more grumbles) (Re: Msg 11617) Date: 11-AUG 22:48 Programming It should be noted, from my own experience, that while LSC is very fast, it goes to disk a lot, at least with my own system (FatMac, old ROM, externa drive). LSC will probably be a dream with a hard disk and TMON, so anyone interested in buying me a hrad disk, please tell me. Really though, LSC not only requires a lot of RAM, but to do real seriouis work probably requires a hard disk too. ------------------------------ From: PEABO (11623) Subject: RE: lightspeed C (more grumbles) (Re: Msg 11622) Date: 11-AUG 22:52 Programming Have you had much trouble with the Project file getting big? I have noticed that is worth while compacting the projects every once in a while, and I would expect that to be much more noticeable on a floppy system. A feature I would very much like to have in LSC is a way of unloading and compacting a project (ie.e, so that the next time I reference it I go through -a complete load and compile of all its components). I would do this routinely with things that I have hanging around but which I am not working on all the time. And it would be nice to be able to rearrange segments (the Mac may not care which segment is which, but I do, when I'm looking at the project's component listing). peter ------------------------------ From: JOSEF (11629) Subject: RE: lightspeed C (more grumbles) (Re: Msg 11623) Date: 11-AUG 23:29 Programming An excellent suggestion, peter! Just the other day I was thinking about all the multiple copies of <MacTraps> and <Stdio> that I must have lying around in various projects on my hard disk. (I guess that's what hard disks are for!) Joe ------------------------------ End of Delphi Mac Digest ************************ ------- Next, history, delete, reply, help, etc.? @